REMARKS 

Applicant thanks Examiner for the detailed review of the application. Examiner currently rejects 
applicant's claims 1, 5-6, 10-11, 15-16, 19, 23, 25-26, 28-34, and 36-38 under 35 U.S.C 103(a) as being 
unpatentable over Clark et al (US 5, 1 87,780), herein referred to as Clark, in view of Zimmerman ("OSI 
Reference Model"). 

Applicant's claim 1 includes the following limitations, "a type field to specify a transaction 
type. . .wherein the format field and the type field together indicate a packet type," (emphasis added). As 
disclosed in applicant's claim 1 the transaction type is selected from a group consisting of a memory request, 
an input/output request, a configuration request and a message request. In addition, embodiments of packet 
types are illustrated in applicant's description in Table 2. Claim 5 further includes examples of packet types 
including a memory read request, a memory write request, an input/output (10) read request, an 10 write 
request, a configuration read, a configuration write, a message request, a message request with data, a 
message for advanced switching, a completion without data, a completion with data, and a completion for 
lock memory read. 

In contrast, Clark discloses the following: 

The header and information portion 22 of the packet 
20 of FIG. 2 includes a type or command field 24 speci- 
fying what type of message is being transmitted, fol- 
lowed by a length field 25 specifying the length of the 
message expressed as the number of bytes. An address 

As can be seen, Clark only disclose the use of length field 25 and type or command field 24 separately to 

define the message, such as the type of message and the length of the whole message. However, applicant's 

claim 1 differs in many respects from this disclosure. First, the format field provides a size of the packet 

header, not the whole message, i.e. message packet 20. Second, the type field in applicant's claim 1 is to 

specify a transaction type and a combination of the format field and the type field to specify a packet type, as 

described above. Clark does not disclose or suggest use of any fields to indicate two type, such as a basic 

transaction type and a specific packet type, but only a single message type from single type field 24. 

Applicant's claim 6 includes the limitation, "an additional field to hold additional information, 
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wherein the format field and the type field together specify a type of additional information to be held 

in the additional field," (emphasis added). In contrast Clark only discloses the following: 

be from zero to 4089 bytes in length. An acknowledge 
packet is of the same format as the packet 20 of FIG. 2, 
but it has a zero-length data field 29, and it has no length 
field 25; the type field 24 of an acknowledge packet has 
a certain code for a positive acknowledge and another 
code for a negative acknowledge or NAK. 

As can be seen, Clark only suggests that the type field itself as a code for a positive acknowledge and another 

code for a negative acknowledge, but does not disclose another field including a different type of information 

based on a format and a type field. The header of applicant's claim 6 includes a type of additional 

information based on the format field and the type field. Embodiments described in the description are 

illustrated in Figures 4-8. For example, in a request packet last double word enable information and first 

double word enable information are included in an additional field. However, for a message the additional 

field includes message code information, and for a completion the additional field includes completion status 

information. Clark docs not describe, disclose, or suggest different types of information in any additional 

field, such as field 26-28, based on other fields of the header, as in applicant's claim 6. 

Referring next to applicant's claim 1 1, the following element is included, "the transaction layer to 

determine a type of additional information in the additional field based on the format field and the type field 

together." Similar to the discussion immediately above, Clark also does not disclose determining a type of 

information in an additional field of a header based on other fields of the header. As disclosed in applicant's 

embodiments, which are discussed above, a field of the header is set to hold different information, such as 

enable information, completion information, or message information based on the packet type specified by 

the format and type fields. However, Clark does not disclose or suggest the use of fields 24-28 in any similar 

manner. 

Applicant has added new independent claim 39, which includes, "a first field to indicate a size of 
the packet header and to indicate whether the packet is to include a data payload. . .a third field to 
represent a length of the data payload, in response to the first field indicating the packet is to include a 
data payload." As illustrated above in the excerpt from Clark, only a single length/size field, i.e. size field 25 
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is disclosed. In contrast, applicant's claim 39 includes two length/size fields; a first field to indicate a size of 
the packet header and a third field to represent a length of the data payload, while Clark only describes length 
field 25 in the header specifying the length of the overall message. 

As Zimmerman only discusses the 7 layers of networking protocol and there is no discussion of 
packet headers or fields, applicant respectfully submits that Zimmerman also does not disclose the 
aforementioned elements/limitations. Therefore, applicant respectfully submits that independent claims 1, 6, 
11, and 39, as well as their dependent claims, are now in condition for allowance for at least the reasons 
stated above. 

If there are any additional charges, please charge Deposit Account No. 50-0221. If a telephone 
interview would in any way expedite the prosecution of the present application, the Examiner is invited to 
contact David P. McAbee at (503) 712-4988. 

Respectfully submitted, 
Intel Corporation 

Dated: August 24, 2007 /s/David P. McAbee/Reg. No. 58.104/ 
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